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Beschreibung 

* 

Verfahren zur Herstellung einer Verbinciung zwischen einem 
Dienstanforderer (Client) und einem Dienstanbieter (Server) 
in einem dezentralen Mobilfunknetz 

Die Erfindung betrifft ein Verfahren zur Herstellung einer 
Verbindung zwischen einem Dienstanf ojrderer (Client) und einem 
Dienstanbieter (Server) in einem dezentralen Mobilfunknetz 
mit Dienst- /Dienstanbieter- Suchservice (Service Discovery) , 
bei dem der Dienstanforderer (Client) zur Lokalisierung eines 
noch unbekannten Dienstanbieters (Servers) , der einen ge- 
wunschten Dienst zur Verfugung stellt. , eine Dienstanf orde- 
rungsnachricht (Service Discovery Request = SD-REQ) in Form 
einer Multicastnachricht an lokal benachbarte Stationen des 
dezentralen Mobilfunknetz sendet, die IP-Router sind, und 
diese Stationen wiederum die Multicastnachricht an deren 
Nachbarstationen und schlieSlich zum Dienstanbieter (Server) 
weiterleiten, der mit einer Antwortnachricht (Seryice Disco- 
very Reply = SD-REP) antwortet . 

- In zukunftigen offentlichen breitbandigen Funknetzen werden 
die Routingmechanismen (Wegsuchemechanismen) von Ad Hoc- 
Netzwerken (dezentrale Netzwerke mit vorzugsweise mobilen 
Stationen) zum Einsatz kommen. Das Ad-hoc Routing Protokoll 
basiert auf der IP (Internet Protocol) Pake tvermitt lung und 
hat die Aufgabe, innerhalb des Funknetzes einen Weg von dem 
Ursprungs- zu dem Zielknoten eines Datenf lusses zu finden. Im 
Fall, dass keine direkte Verbindung besteht, besteht die Auf- 
gabe darin, einen Satz von Routern aiaszuwahlen, der die Uber- 
tragung der IP-Pakete ermoglicht. Die Router leiten empfange- 
ne IP-Pakete an den jeweils nachsten Router oder der Ziel sta- 
tion weiter. 



Es gibt verschiedene Routingprotokolle fur Ad-hoc Netze. Die 
Aufgabe der Wegesuche wird in unterschiedlicher Weise zum 
Beispiel mit AODV (Ad hoc On Demand Distance Vector Routing 
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Protocol) , DSR (Dynamic Source Routing Protocol for Mobile Ad 
Hoc Networks) , DSDV (Destination-Sequence Distance-Vector for 
mobile Computers) Protokollen geldst. Im folgenden wird bei- 
spielsweise das AODV-Protokoll betrachtet. 

5 

Allen genannten Routingprotokollen ist gemeinsam, dass zum 
Start der Wegsuche die IP-Adresse der Empf angerstation als 
Eingangsparameter dient. Das Routingprotokoll sucht, basie- 
rend auf dieser Information, einen gunstigen Weg durch das 

10 Netz. Die Signal is ierung der Nachrichten des Routingproto- 

kolls tragt bei steigender Mobilitat der Stationen mit einem 
grofien Anteil zum sogenannten Signalisierungsoverhead ("Bal- 
last" der Telekommunikation) bei. Bei den reaktiven Rou- 
tingprotokollen, wie AODV, werden "Route Request (R-REQ) " - 

15 Nachrichten uber das gesamte Funknetzwerk geflutet, wenn eine 
Route noch nicht bekannt oder veraltet ist. 

Es gibt verschiedenste Anwendungsf alle, bei dem die Adresse 
einer Zielstation zunachst nicht bekannt ist, es fehlt also 

20 die Eingangsinformation fur das Routing. Das ist zum Beispiel 
der Fall, wenn der mobile Endkunde zu einer Station Kontakt 
aufnehmen mochte, die einen bestimmten Dienst zur Verfiigung 
stellt, ohne dass ihm der Rechnername oder die IP-Adresse be- 
kannt ist. Beispiele hierfur waren, die Abfrage von ortsbezo- 

25 genen Information, die Abfrage von lokale Wetterinf ormation 
oder Positionsabf rage eines Bankautomaten in der Nahe. 

Die Suche nach einem Dienstanbieter (Service Discovery) kann 
zentral mit einem 11 Verzeichnis-Dienst 11 oder dezentral gesche- 

30 hen. Im dezentralen Fall sendet der Dienstanf orderer (Client) 
alien Stationen in einer gewahlten Entfernung eine "Service 
Discovery Request (SD-REQ) 11 -Nachricht . Die Stationen, die den 
entsprechenden Dienst anbieten (Server), antworten darauf. 
Die Antwort heiSt dann "Service Discovery Reply (SD-REP) M - 

35 Nachricht. Bei der SD-REQ-Nachricht handelt es sich urn eine 
Multicastnachricht, die alle Stationen in einem geograf ischen 
Bereich erreichen. Jede Station des Ad Hoc-Netzwerks reicht 
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die Multicastnachricht an ihre Nachbarstationen weiter. Ser- 
ver-Stationen antworten mit einer detailliert Beschreibung 
des angeforderten Dienstes in der SD-REP-Nachricht . 

Vorteilhaf terweise nimmt nun die Antwort eines Servers den 
5 Weg, den die "Service Discovery" -Nachricht kurz zuvor zuruck- 
gelegt hat. Wahrend bei dem Rout ingp rot okoll AODV, prinzi- 
piell ein entsprechendes Verhalten vorhanden ist, ist dies 
bei SD-REQ- und SD-REP-Nachrichten jedoch nicht vorgesehen. 
Da Routingtabellen in den Routern nur bei der Verwendung des 
10 AODV-Protokolls angepasst werden, nicht aber beim Weiterlei- 
ten von Nachrichten des Service Discovery-Protokolls, muss 
gegenwartig nach dem Service Discovery auch noch eine Route 
zwischen den entsprechenden Stationen gefunden werden. 

15 Die folgende Sequenz musste bei der derzeitigen Definition 
des Ad hoc-Routingprotokolls befolgt werden: 

- Der Client flutet eine SD-REQ-Nachricht . 

- Bei jedem Server, der den Dienst anbietet, wird die Wegesu- 
che nach dem Dienstanf orderer gestartet. Das heifit jeder Ser- 

20 ver flutet R-REQ-Nachrichten, urn eine Route zum Client zu er- 
zeugen. 

- Der Client antwortet jeweils mit R-REP. 

- Der Pfad zwischen Server und Client existiert nun und der 
Server kann mit SD-REP antworten. 

25 - Der Client kann nun gegebenenf alls einen Server aussuchen 
und eine Verbindung zu diesem Server herstellen, um den ge- 
suchten Dienst in Anspruch zu nehmen oder weitere Informatio- 
nen zu erhalten. 

3 0 Eine weitere Losung fur die Vermeidung von Multicastnachrich- 
ten beim Service Discovery ist, dass Server ihre Dienste bei 
einem zentralen Server registrieren. Clients wurden dann zu- 
nachst diesen zentralen Server kontaktieren, um die IP- 
Adressen der Server zu bestimmen, die einen gesuchten Dienst 

35 anbieten. Hat ein Client nun einen Server ausgesucht, kennt 
er auch dessen IP-Adresse, und kann dann das normale R-REQ 
schicken, um einen Weg zu dem Server zu bestimmen. 
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Nachteil dieser zweiten Losung ist, dass eine oder auch meh- 
rere Server-Datenbanken eingerichtet werden mussen. Die Ad- 
ressen dieser Stationen mussen irgendwie bekannt gegeben wer- 
5 den. Zudem muss die Client -Station dennoch Multicastnachrich- 
ten fluten, urn die Route zu der Server-Datenbank und bei Be- 
darf die Route zu dem Server zu bestimmen, 

Es ist daher Aufgabe der Erfindung, ein Verfahren zur Her- 
10 stellung der Verbindung zwischen einem Dienstanf orderer 

(Client) und einem Dienstanbieter (Server) in einem dezentra- 
len Mobil funknetz mit Dienst-/Dienstanbieter-Suchservice 
(Service Discovery) zu finden, welches das Problem des Signa- 
lisierungsoverheads minimiert. 

15 

Diese Aufgaben der Erfindung werden durch das Verfahren mit 
den Merkmalen des Patentanspruches 1 gelost. Vorteilhafte 
Weiterbildurigen der Erfindung sind Gegenstand untergeordneter 
Patentanspruche. 

20 

Die Erfinder haben erkannt, dass es moglich ist, den Signali- 
sierungsoverhead zu minimieren, wenn auch die vom Dienstan- 
f orderer (Client) gesendete Multicastnachricht, die beim Auf- 
suchen des Dienstanbieters (Server) verwendeten Routingtabel- 
25 len in den Routern, mit Weginf ormationen zum Dienstanf orderer 
(Client) versehen wird. 

Entsprechend diesem Erf indungsgedanken schlagen die Erfinder 
vor, das an sich bekannte Verfahren zur Herstellung einer 

30 Verbindung zwischen einem Dienstanforderer (Client) und einem 
Dienstanbieter (Server) in einem dezentralen Mobil funknetz 
mit Dienst-/Dienstanbieter-Suchservice (Service Discovery) , 
bei dem der Dienstanforderer (Client) zur Lokalisierung eines 
noch unbekannten Dienstanbieters (Servers) , der einen ge- 

35 wunschten Dienst zur Verfugung stellt, eine Dienstanf orde- 
rungsnachricht (Service Discovery Request = SD-REQ) in Form 
einer Multicastnachricht an lokal benachbarte Stationen des 
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dezentralen Mobilf unknetz sendet, die IP-Router sind, und 
diese Stationen wiederum die Multicastnachricht an deren 
Nachbarstationen und schlieSlich zum Dienstanbieter (Server) 
weiterleiten, der mit einer Antwortnachricht (Service Disco- 
very Reply = SD-REP) antwortet, dahingehend zu verbessern, 
dass zur Zuruckverfolgung des Weges zum Dienstanf orderer 
(Client) den Routingtabellen der Stationen die Weginf ormatio- 
nen der Dienstanf orderungsnachricht und dessen Antwortnach- 
richt beigefugt werden. 

Hierdurch ist es moglich, die bisher vom Dienstanbieter not- 
wendigen Wegsuchanf ragen (Route Request = R-REQ) zu vermei- 
den, wodurch der Signalisierungsoverhead im Mobilf unknetz er- 
heblich reduziert wird. 

In einer besonderen Ausfiihrung des Verfahrens kann die 
Dienstanf orderungsnachricht (Service Discovery Request = SD- 
REQ) des zumindest einen Dienstanf orderers (Client) urn Ele- 
mente einer Suchnachricht (Route Request R-REQ) des zumindest 
Dienstanbieters (Servers) erweitert werden. 

Beim R-REQ des AODV-Protokolls waren dies alle Elemente auEer 
diejenigen, die die unbekannte Zieladdresse betreffen, das 
heiSt "D", W G" , "Destination IP Address" und destination Se- 
quence Number" . 

In einer besonderen Ausfiihrung wird auSerdem die Antwortnach- 
richt (Service Discovery Reply = SD-REP) des zumindest einen 
Dienstanbieters (Server) urn alle Elemente einer Wegantwort- 
nachricht (Route Reply = R-REP) des zumindest einen Dienstan- 
forderers (Client) erweitert. 

Im Fall des AODV-Protokolls kann auf Grund der zusatzlichen 
Inf ormationselemente jede Station, die diese SD-REQ- und SD- 
REP-Nachrichten empfangt, ihre internen Routingtabellen aktu- 
alisieren, so dass eine zweite explizite Wegesuche entfallen 
kann. 
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Es ist vorteilhaft, wenn als Wegsucheprotokoll , vorzugsweise 
ein AODV- oder ein DSR-Protokoll verwendet wird, dass in der 
Dienstanf orderungsnachricht (Service Discovery Request) und 
in der Antwortnachricht (SD-REP) integriert wird. 

Diese Wegsuchprotokolle gehoren zu den reaktiven Routingpro- 
tokollen, wodurch eine sich andernde oder veraltete Route 
einfach aktualisiert werden kann. 

Alternativ dazu ist es vorteilhaft, wenn das Routingproto- 
koll, vorzugsweise AODV oder DSR, dahingehend erweitert wird, 
dass es bei Empfang von den erweiterten SD-REQ- und SD-REP- 
Nachrichten die lokalen Routingtabellen entsprechend mit den 
Weginformationen aktualisiert. 

Im Folgenden wird die Erfindung anhand bevorzugter Ausfuh- 
rungsbeispiele mit Hilfe der Figuren 1 bis 6 beschrieben, wo- 
bei in den Figuren folgende Bezugszeichen verwendet werden: 
1: Dienstanf orderer (Client) /Station des Dienstanf orderers 
(Client); 2: weitere Stationen; 3: Dienstanbieter (Ser- 
ver) /Station des Dienstanbieters (Server); 4: Service Disco- 
very Request; 4a: Service Discovery Request mit integrierten 
Routinginf ormationselementen; 5: Route Request; 6: Route 
Reply; 7: Service Discovery Reply; 7a: Service Discovery 
Reply mit integrierten Routinginf ormationselementen; 8: Ad 
Hoc-Netzwerk. 

Die Figuren zeigen im einzelnen: 

Figur 1: Ad Hoc-Netzwerk, in dem ein Client eine Dienstan- 
forderungsnachricht in Form einer Multicastnach- 
richt aussendet; 

Figur 2: Ad Hoc-Netzwerk aus Figur 1, in dem zwei Server ei- 
ne Wegsuchnachricht nach dem Client ebenfalls in 
Form jeweils einer Multicastnachricht aussenden; 
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Figur 3: Ad Hoc-Netzwerk aus den Figuren 1 und 2, in dem der 

Client eine Antwort auf die Wegsuchnachricht zu den 

Servern zurucksendet ,- 
Figur 4: Ad Hoc-Netzwerk aus den Figuren 1 bis 3, in dem die 
5 Server den gewunschten Dienst dem Client anbieten; 

Figur 5: Ad Hoc-Netzwerk, in dem ein Client eine Dienstan- 

forderungsnachricht in Form einer besonderen Multi- 

castnachricht aussendet ; 
Figur 6: Ad Hoc-Netzwerk aus Figur 5, in dem zwei Server den 
10 gewunschten Dienst dem Client anbieten . 



In den Figuren 1 bis 4 wird das bekannte Verfahren zur Her- 
stellung einer Verbindung zwischen einem Dienstanforderer 
(Client) 1 und einem Dienstanbieter (Server) 3 in einem Ad 

15 Hoc-Netzwerk 8 gezeigt. Der Ubersichtlichkeit wegen, werden 
die verschiedenen Verf ahrensschritte separat in den Figuren 1 
bis 4 dargestellt. Das Ad Hoc-Netzwerk 8 besteht in der ge- 
zeigten Ausfuhrung aus einem Dienstanforderer (Client) 1, der 
einen bestimmten Dienst aus dem Netzwerk 8 abrufen will. Au- 

2 0 Serdem sind in diesem Ad Hoc-Netzwerk 8 mehrere Stationen 2 

vorhanden, die auch mobil sein konnen und verschiedene Diens- 
te anbieten konnen. Alle Stationen des Ad Hoc-Netzwerks 8 
sind Router und konnen uber das verwendete Routingprotokoll 
Verbindungen zu anderen Stationen des Ad Hoc-Netzwerkes 8 

2 5 schaffen. Den beiden speziellen Stationen, die den gewunsch- 

ten Dienst des Dienst anforderers (Client) 1 anbieten, wurde 
das Bezugszeichen 3 vergeben. Diese sind dann mir Dienstan- 
bieter (Server) 3 bezeichnet. Die Figuren zeigen: 

3 0 Die Figur 1 zeigt, wie der Dienstanforderer (Client) 1, der 

einen gewunschten Dienst, zum Beispiel Wetterdaten in- einem 
bestimmten Gebiet, zur Bemachtigung/Erlangen des Dienstes - 
vorgeht. Da dem Dienstanforderer (Client) 1 die Serveradres- 
se/IP-Adresse desjenigen Dienstanbieter (Server) 3, der die 
3 5 Wetterdaten zur Verfugung stellen kann, in der Regel nicht 
bekannt ist, wird der Dienstanforderer (Client) 1 eine 
Dienstanf orderungsnachricht , oder auch mit Service Discovery 
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Request 4 bezeichnet, in das Ad Hoc-Netzwerk 8 schicken. Die 
Service Discovery Request 4 (gepunktete Pfeile) wird vom 
Dienstanforderer (Client) 1 in der Regel als Multicast- oder 
Broadcastnachricht an geographisch benachbarte Stationen 2 
5 gesendet. Diese Multicast- oder Broadcastnachricht wird von 
den Stationen 2 an deren benachbarte Stationen 2 weiter ge- 
leitet 7 bis diese letztendlich auch den oder die richtigen 
Dienstanbieter (Server) 3 erreichen. Das Verteilen aller hier 
genannten Nachrichten und insbesondere das "Uberfluten" des 

10 Ad Hoc-Netzwerkes 8 mit diesen Nachrichten wird als Signali- 
sierungsoverhead bezeichnet . Den beiden Dienstanbietern (Ser- 
ver) 3 geht lediglich die Dienstanf orderungsnachricht bezie- 
hungsweise die Service Discovery Request 4 des Dienstanf orde- 
rers (Client) 1 ein. Der Weg oder der Pfad auf dem diese Ser- 

15 vice Discovery Request 4 vom Dienstanforderer (Client) 1 zum 
Dienstanbieter (Server) 3 gekommen ist, kann nicht unter Ser- 
vice Discovery (Dienst-/anbieter Suchservice) nachvollzogen 
we r den. 

2 0 Die Figur 2 zeigt nun wie die beiden Dienstanbieter (Server) 
3 den Dienstanforderer (Client) 1 lokalisieren. Die beiden 
Dienstanbieter (Server) 3 senden in Form einer Multicastnach- 
richt eine Wegsuchnachricht , oder mit Route Request 5 be- 
zeichnet, an deren lokal benachbarte Stationen 2. Die Route 

2 5 Request 5 wird ahnlich der Service Discovery Request 4 vom 

Dienstanforderer (Client) 1 aus Figur 1 von Station 2 zu Sta- 
tion 2 und schlie£lich zum Dienstanforderer (Client) 1 wei- 
tergeleitet. Jedoch im Unterschied zur Service Discovery Re- 
quest 4 wird bei der Route Request 5 der Weg oder Pfad des 

3 0 Absenders, also der beiden Dienstanbieter (Server) 3, kennt- 

lich gemacht. So konnen beim Empfang von Route Request Nach- 
richten 5 des AODV-Protokolls die Stationen 2 ihre Routingta- 
bellen anpassen. Diese "Wegkennzeichnung" wird durch die ge- 
punkteten Kreise der Stationen 2 angedeutet . Auch bei diesem 
35 Verf ahrensschritt , in dem der Dienstanbieter (Server) 3 den 
Weg zum Dienstanforderer (Client) 1 sucht, kommt es zu einem 
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Uberfluten des Netzwerkes, in der Annahme, dass eine Route zu 
Station 1 des Dienstanf orderer (Clients) noch unbekannt ist . 

In Figur 3 wird dargestellt, wie der Dienstanf orderer 
5 (Client) 1 die Wegsuchnachricht Route Request 5 der beiden 
Dienstanbieter (Server) 3 beantwortet. Der Dienstanf orderer 
(Client) 1 kann nun nachvollziehen auf welchen Wegen/Pfaden 
die Route Request 5 der beiden Dienstanbieter (Server) 3 ihn 
erreicht hat. Der Dienstanf orderer (Client) 1 schickt eine 

10 Antwort "Route Reply 6" auf jede Wegsuchnachricht der beiden 
Dienstanbieter (Server) 3 f zum Beispiel auf dem Weg/Pfad, den 
die jeweils zugehorige Wegsuchnachricht genommen hatte. Diese 
Antwort Route Reply 6 wird durch einen durchgezogenen Pfeil 
symbolisiert , urn das Bekanntsein des Weges /Pfades zu kenn- 

15 zeichnen. 

In Figur 4 wird dargestellt, wie die beiden Dienstanbieter 
(Server) 3 auf dem bestimmten Weg/Pfad ihre Dienstbeschrei- 
bung in Form einer Service Discovery Reply 7 dem Dienstanfor- 
2 0 derer (Client) 1 ubermitteln. Der Dienstanf orderer (Client) 1 
kann nun zum Beispiel wahlen, welchen Dienstanbieter (Server) 
3 er in Anspruch nimmt . 

An dem, anhand der Figuren 1 bis 4 erlauterten, Verfahren' 
25 wird deutlich, wie aufwendig die Lokalisierung im Ad Hoc- 
Netzwerk 8 ist. So zeigen speziell die Figuren 1 und 2 den 
Effekt des Signalisierungsoverhead. Die "Uberf lutung" des Ad 
Hoc -Netzwerkes 8 mit zu vielen Nachrichten soil aber gerade 
vermieden werden. Hierzu wird in den Figuren 5 und 6 ein neu- 
30 es Verfahren zur Herstellung der Verbindung zwischen einem 
Dienstanf orderer (Client) und einem Dienstanbieter (Server) 
beschrieben, welches den Signalisierungsoverhead zumindest 
reduziert . 

35 Die Figur 5 zeigt das selbe Ad Hoc-Netzwerk 8, wie in den Fi- 
guren 1 bis 4. Analog zu Figur 1 sendet der Dienstanf orderer 
(Client) 1, der einen noch unbekannten Dienstanbieter (Ser- 
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ver) 3, der einen gewiinschten Dienst anbietet, aufsucht, eine 
Multicastnachricht an lokal benachbarte Stationen 2. Im Un- 
terschied zu Figur 1 besteht diese Multicastnachricht aus ei- 
ner Dienstanf orderungsnachricht , auch Service Discovery Re- 
5 quest 4a genannt, in der Inf ormationselemente des Route Re- 
quests integriert sind. Durch die integrierte Routingnach- 
richt werden beim Weiterleiten dieser Multicastnachricht von 
Station 2 zu benachbarter Station 2, die Routingtabellen 
durch das erweiterte Routingprotokoll angepasst. Durch das 

10 Anpassen der Routingtabellen kann der Weg/Pfad zum Dienstan- 
forderer (Client) 1 zuruckverf olgt werden. Diese "Wegkenn- 
zeichnung/Pf adkennzeichnung" wird durch die gepunkteten Krei- 
se der Stationen 2 angedeutet. An dieser Stelle sei erwahnt, 
dass auch die Stationen 1 und 3, also der Dienstanf orderer 

15 (Client) und die beiden Dienstanbieter (Server) , gleichzeitig 
auch Router sind. Das soli heiSen, auch diese erzeugen, sen- 
den und empfangen und verarbeiten Nachrichten des Routingpro- 
tokolls und verhalten sich entsprechend den Regeln des Rou- 
tingprotokoll s . Insbesondere haben sie auch Routingtabellen. 

20 Aus diesem Grund sind auch die Stationen 1 und 3 in den Figu- 
ren 5 und 6 durch Kreise, mit gepunkteter Linie, dargestellt. 

In der Figur 6 wird dargestellt, wie die beiden Dienstanbie- 
ter (Server) 3 auf dem nun bekannten Weg/Pfad ihre Dienstbe- 

25 schreibung in Form einer Service Discovery Reply 7a den 

Dienstanf orderer (Client) 1 ubermitteln. Im Unterschied zu 
Figur 4 besteht diese Nachricht aus einer Antwortnachricht , 
auch Service Discovery Reply 7a genannt, in die alle Inf orma- 
tionselemente des Route Replys integriert sind. Durch die in- 

30 tegrierte Routingnachricht werden beim Weiterleiten dieser 
Nachricht von Station 2 zu benachbarter Station 2, die Rou- 
tingtabellen durch das erweiterte Routingprotokoll angepasst. 
Durch das Anpassen der Routingtabellen kann der Weg/Pfad zum 
Dienstanbieter (Server) 3 zuruckverf olgt werden. Diese w Weg- 

35 kennzeichnung/Pf adkennzeichnung" wird durch die gepunkteten 
Kreise der Stationen 2 dargestellt. Der Dienstanf orderer 
(Client) 1 kann nun zum Beispiel wahlen, welchen Dienstanbie- 
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ter (Server) 3 er in Anspruch nimmt und zum Beispiel eine Da- 
tenverbindung, ohne weitere Wegsuche, zu einem von beiden 
auf baut . 

Der Vorteil an diesem neuen Verfahren ist, dass der Signali- 
sierungsoverhead, der beim Versenden von Wegsuchnachrichten 
vom Dienstanbieter (Server) 3 zum Dienstanf orderer (Client) 1 
in Form von Multicastnachrichten, wie sie in Figur 2 gezeigt 
werden, entf alien kann. 



Insgesamt" wird ein neues Verfahren zur Herstellung einer Ver- 
bindung zwischen einem Dienstanf orderer (Client) und einem 
Dienstanbieter (Server) in einem dezentralen Mobilf unknetz, 
vorzugsweise in einem Ad Hoc -Mobilf unknetz oder einem reakti- 
15 ve Ad Hoc-Netzwerk-Protokolle nutzendes Mobilf unknetz , mit 
Dienst-/Dienstanbieter-Suchservice (Service Discovery) zur 
Verfugung gestellt, welches weniger Multicastnachrichten be- 
notigt und somit das Problem des Signalisierungsoverheads mi- 
nimiert . 



Es versteht sich, dass die vorstehend genannten Merkmale der 
Erfindung nicht nur in der jeweils angegebenen Kombination, 
sondern auch in anderen Kombinationen oder in Alleinstellung 
verwendbar sind, ohne den Rahmen der Erfindung zu verlassen. 
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Patentanspruche 

1. Verfahren zur Herstellung einer Verbindung zwischen einem 
Dienstanforderer (Client) (1) und einem Dienstanbieter 
(Server) (3) in einem dezentralen Mobilfunknetz (8) mit 
Dienst-/Dienstanbieter-Suchservice (Service Discovery) , 
bei dem der Dienstanforderer (Client) zur Lokalisierung 
eines noch unbekannten Dienstanbieters (Servers) (3) , der 
einen gewunschten Dienst zur Verfugung stellt, eine 
Dienstanf orderungsnachricht (Service Discovery Request = 
SD-REQ) (4) in Form einer Multicastnachricht an lokal be- 
nachbarte Stationen (2) des dezentralen Mobilfunknetz (8) 
sendet, die IP-Router sind, und diese Stationen (2) wie- 

' derum die Multicastnachricht an deren Nachbar stationen 
(2) und schlieiSlich zum Dienstanbieter (Server) (3) wei- 
terleiten, der mit einer Antwortnachricht (Service Disco- 
very Reply = SD-REP) (7) antwortet, 
dadurch gekennzeichnet , 

dass zur Zuruckverf olgung des Weges zum Dienstanforderer 
(Client) (1) den Routingtabellen der Stationen (2) die 
Weginformationen der Dienstanf orderungsnachricht und des- 
sen Antwortnachricht beigefugt werden. 

2. Verfahren gemafi dem voranstehenden Patentanspruch 1, 
dadurch gekennzeichnet, 

dass die Dienstanforderungsnachricht (SD-REQ) (4) des zu- 
mindest einen Dienstanf orderers (Client) (1) urn Elemente 
einer Suchnachricht (Route Request = R-REQ) (5) des zu- 
mindest einen Dienstanbieters (Servers) (3) erweitert 
wird. 
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3 . Verf ahren gemafi einem der voranstehenden Patentanspruche 
1 und 2, 

dadurch gekennzeichnet, 

dass die Antwortnachricht (SD-REP) (7) des zumindest ei- 
nen Dienstanbieters (Server) urn alle Elemente einer Weg- 
antwortnachricht (Route Reply = R-REP) (6) des zumindest 
einen Dienstanf orderers (Client) (1) erweitert wird. 

4 . Verf ahren gemafi einem der voranstehenden Patentanspruche 
1 bis 3, 

dadurch gekennzeichnet, 

dass als Wegsucheprotokoll , vorzugsweise ein AODV- oder 
ein DSR-Protokoll verwendet wird, dass in der Dienstan- 
forderungsnachricht (SD-REQ) (4) und in der Antwortnach- 
richt (SD-REP) (7) integriert wird. 



5. , Verf ahren gemafi einem der voranstehenden Patentanspruche 
1 bis 4, 

dadurch gekennzeichnet , 

dass das Routingprotokoll , vorzugsweise AODV oder DSR, 
dahingehend erweitert wird, dass es bei Empfang von den 
erweiterten SD-REQ-Nachrichten (4a) und SD-REP- 
Nachrichten (7a) die lokalen Routingtabellen entsprechend 
mit den Weginf ormationen aktualisiert . 
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FIG 2 

Stand der Technik 
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FIG 4 

Stand der Technik 
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